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ABSTRACT 


Currently, reasoning about key lengths within a security scheme involves utilizing 
generalized recommendations or conducting lengthy manual analyses of how security pa¬ 
rameters relate to the security of the scheme. In this paper, we provide the tools necessary 
for automating reasoning about key lengths and effective security within a security scheme. 
We first formalize the reasoning about cryptographic proofs within an attack tree structure, 
then expand attack tree methodology to include cryptographic reductions. We then provide 
the algorithms for maintaining and automatically reasoning about these expanded attack 
trees. We provide a software tool that utilizes machine-readable proof and attack metadata 
and the attack tree methodology to provide rapid and precise answers regarding security 
parameters and effective security. This eliminates the need to rely on generalized recom¬ 
mendations and provides timely reanalysis when newfound attacks or proofs surface. We 
validate our software tool within the Schnorr public-key signature scheme as a case study. 
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CHAPTER 1: 

Introduction 


Currently, when an organization reasons about keylength, it is left to choose from an 
array of sometimes conflicting recommendations provided by several organizations. These 
recommendations are typically generalized and furnish conservative values. Furthermore, 
the organizations that maintain them tend to update them with a periodicity of a year or 
more regardless of newly published papers or newly found attacks that may affect them. 

The alternative to this method involves a cryptographer reasoning about keylength through 
an analysis relating security parameters of a particular scheme to its effective security. This 
is done with security proofs (typically manual) that relate the parameters and effective 
security. This method is less general than the recommendations and can be updated as often 
as one can afford; however, it can be arduous and requires experts to complete. 

We explore developing a software tool that can automate the reasoning about keylength 
for a cryptographic scheme. This software tool applies machine-readable proof and attack 
metadata using an attack tree approach to provide timely and accurate answers concerning 
security parameters and effective security. Being derived from an attack tree methodology, 
this approach naturally inherits extensibility and modularity. This research expands tradi¬ 
tional attack tree analysis to consider symbolic constraints related to proof tightness and 
attack cost. This allows experts in one domain (e.g., attacks employing the general number 
field sieve) to inform experts from another domain (e.g., the relationship between the sub¬ 
group discrete log problem and some, specific hybrid signature scheme) by supplying new 
modules with appropriate metadata. This makes this type of reasoning significantly more 
dynamic. Its modular design allows organizations to incorporate new attack metadata and 
make prompt, informed reactions to new attacks or security announcements. Furthermore, 
precisely and immediately re-generating analyses related to security parameters enables 
counter-factual reasoning about these proofs: would improving the tightness bounds of 
prior work effectively strengthen the security of a scheme (or does some other factor cre¬ 
ate a bottleneck)? Given some selection parameters, what is the effective security of the 
resulting scheme? What parameters should one select to yield a desired, target effective 
security? 
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Our research contributes the following to the area of reasoning about the effective security 
of a security scheme: 


• We formalize a method for reasoning about cryptographic proofs using attack trees; 

• We expand attack tree analysis to include cryptographic reductions and provide al¬ 
gorithms for maintaining and automatically reasoning about these enhanced, crypto¬ 
graphic attack trees; 

• We provide a proof-of-concept software tool, implemented in Python and leveraging 
the SymPy symbolic solver library; and 

• We validate our tool using the Schnorr public-key signature scheme as a case study, 
comparing the results of our automated analysis with relevant, existing keylength 
recommendations. 


1.1 Organization 

In Chapter 2, we discuss existing methods for determining an appropriate keylength for a 
security scheme and review existing work on automated cryptographic proving. In Chap¬ 
ter 3, we formalize reasoning within attack tree structures, expand attack tree 
methodology to include cryptographic reductions and introduce our case study, the 
Schnorr signature scheme. In Chapter 4, we cover the concept of operations of our 
software tool and some characteristics we set to achieve with our design. In Chapter 5, 
we discuss our software tool implementation and discuss the algorithms driving the 
analysis engine of our software tool. We then examine some of the results of the 
software tool and compare these results with existing methods. In Chapter 6, we conclude 
and discuss future work. 
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CHAPTER 2: 
Background 


In this chapter, we review current keylength analysis techniques, the properties of crypto¬ 
graphic proofs required to perform a detailed keylength analysis and related research on 
automated proving for cryptographic constructions. 


2.1 Keylength Analysis 

Reasoning about cryptographic parameters requires an mathematical analysis relating the 
schemes’ security parameters to the effective security of the resulting scheme. When a 
scheme is argued to have effective security of n bits given some choice of parameters, this 
characterizes the cost of attacking the scheme as equivalent in cost to brute-forcing some 
notional, symmetric system with an n-bit secret key, i.e., an effort of approximately 2” 
operations [1]. For many schemes, there is a discrepancy between the security parameter 
and effective security for that scheme, based on the details of the construction and its 
proof of security. For example, 3DES uses three keys each of length 56 bits yet it is well- 
understood this construction does not yield a block cipher with 168-bits of effective security 
(3 X 56 bits); instead, 3DES has been shown to have an effective security of 112-bits. More 
efficient attacks against any system may exist, utilizing vulnerabilities in its implementation, 
in the properties of its underlying building-blocks, in its environment or via its users [1]. 
The scope of our analysis is to those properties and attacks covered by the security proof 
associated with the scheme. 

Cryptography requires a security proof relating parameters to effective security. Both proof 
construction and proof analysis entails domain-expert knowledge and can be a laborious 
and nuanced process. New questions may not be able to re-use the results of prior analysis 
(i.e., when the prior assumptions were not general or when the context is slightly different). 
Instead, new questions may require whole-cloth re-analysis. 

When organizations determine policy or select cryptographic parameters, they may find it 
too costly to conduct an in-depth proof analysis. Instead, they rely on guidance published by 
academic, government and private organizations such as the National Institute of Standards 
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and Technology (NIST), the Bundesamt fur Sicherheit in der Informationstechnik (BSI), 
the National Security Agency and the Internet Engineering Task Force. For example, NIST 
presents “best practice” parameters codified in look-up tables in publications which undergo 
periodic update, every two to four years [2]. During this period, the cost of some attacks 
may reduce, e.g., because of the increase in computer performance, decrease in resource 
cost or the discovery of new attack methods [1]. While the effects of Moore’s law can be 
projected, the effect of new attacks on a system’s effective security may not be apparent 
without a whole-cloth re-analysis. These impacts may not be disseminated until guidance is 
updated, if it is updated. In general, these published “best practice” parameters are intended 
to be relatively conservative; however, as periodic review is a human process, opportunities 
to re-think guidance is perhaps not as timely as circumstances may warrant. Beyond the 
possibility of being outdated, the limited context of the analysis codified in this guidance 
makes it inappropriate to leverage to answer new questions regarding security. 

Referring to one of these “best practice” key length publications is certainly more accessible 
than a complete re-analysis, but it can be cumbersome as well. Furthermore, these guide¬ 
lines are not always in agreement, creating a new hardship involving deciding upon which 
cryptographic guidance is most appropriate. Giry aggregates the keylength guidance from 
organizations, providing this as a resource through an interactive website [3]. It allows one 
to quickly compare the results of each report against one another to aide organizations in 
making a decision about security parameters [3]. While this reduces the workload associ¬ 
ated with reading and interpreting this guidance, by putting each in relatively comparable 
terminology, the timeliness of information and resolving discrepancies remain as problems. 


2.2 Methods for Achieving Provable Security 

To date, it has been common to describe reductionist security proofs in one of two ways, 
as asymptotic guarantees or as concrete guarantees. The asymptotic setting was arguably 
first employed by Rabin in 1979 [4] and has been in relatively common use since. In a 
reductionist security argument, a proof of security involves a reduction between breaking 
the security of the system to solving a computationally hard problem [5]. In the asymptotic 
setting, this reduction yields statements such as “for a sufficiently large security parameter 
A, no polynomial-time adversary has more than non-negligible probability of success in 
breaking the security property for the scheme” [5]. In the concrete setting, introduced 
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by Bellare and Rogaway, the goal is to produce more practice-oriented statements [6]. 
A concrete proof of security yields statements such as “an attacker, within time t and 
employing q queries to a problem-solving oracle O, is able to break the security property 
for the scheme under security parameter A with at most e probability of success” [7]. 

Each type of proof has advantages and disadvantages. For example, it appears some schemes 
are simpler to prove secure in the asymptotic setting. It is not the goal of our research, 
however, to criticize these two paradigms or to determine if one setting is more useful 
than the other, generally. The purpose of our software tool is to provide accurate answers 
regarding security parameters and effective security; thus, we have chosen to reason in the 
concrete security setting. This allows us to precisely characterize the cost of security due 
to the tightness of proof reductions and it allows us to interpret more accurate values for 
attack cost for given security parameters [8]. 


2.3 Automated Proof Generation 

The academic community is continuously striving to create new cryptographic proof tech¬ 
niques, firmly grounded in mathematical foundations, to provide more easily verifiable 
guarantees with stronger results when analyzing cryptographic constructions [9]. Building 
on the work of Dolev and Yao [10], Kilian and Rogaway [11], Bellare and Rogaway [12] 
and others, the community has sought new methods to verify the correctness of machine- 
readable cryptographic proofs and to generate cryptographic proofs, in either a fully auto¬ 
matic or machine-assisted manner. 

For some examples, Cortier and Warinschi [9] employ an existing tool called Casrul for 
automatically generating sound proofs in the computational model. Barthe et al. intro¬ 
duce EasyCrypt, a tool for machine-assisted security proofs from proof sketches using the 
CertiCrypt framework and available proof verifiers [13]. Blanchet introduces ProVerif, 
a cryptographic protocol verifier in the formal model [14]. Blanchet later extends this 
tool as CryptoVerif, an automatic protocol prover sound in the computational model [15] 
demonstrated to prove secrecy for a number of key exchange protocols. 

Our software tool does not provide automatic proof generation, rather providing automatic 
analysis derived from proofs. The goal of our software tool is to employ concrete security 
proofs to determine guidance about security parameters or deriving effective security. Our 
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software tool uses metadata about eonerete proofs to reason about seeurity parameters and 
effeetive seeurity. In the future, it may be possible to bridge automatie proof generation 
and our software tool. It may be possible to analyze the proofs from automated tools, or 
interpret it direetly using a modified version of our software tool. This would allow the 
ehain of automation to be extended from proof generation to ineluding reasoning about 
effeetive seeurity and reeommending parameters. 
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CHAPTER 3: 

Cryptographic Attack Tree Analysis Model 


The target outcome of this research is a proof-of-concept software tool able to reason about 
effective security, automatically and dynamically, given different parameter options. It uses 
machine-readable proof and attack metadata to provide accurate answers regarding security 
parameters and effective security within a security scheme. Here, we propose a method 
to analyze this metadata based on attack trees. Since our methodology is based on attack 
trees, our software tool inherits many benefits traditionally associated with attack trees, e.g., 
extensibility and modularity. 

We discuss the model and concepts traditionally associated with attack trees in Section 3.1. 
Our methodology expands typical attack tree analysis, however, to consider symbolic con¬ 
straints related to proof tightness and attack costs. Inclusion of those constraints related 
to proof metadata, however, requires attack cost calculations associated with traditional 
attack trees to become more complicated, especially when multiple reductions may exist 
between attack objectives, which we discuss in Section 3.2. We present a case study for this 
methodology in Section 3.3, employing Schnorr’s digital signature scheme. 


3.1 Attack Trees 

To better understand the weaknesses within a system, one can examine the system based on 
known methods of attacking it. An attack tree is a method of representing attacks against 
the system in a tree structure, allowing analysis of attack dependencies and costs. This 
method has been popularly discussed by Schneier and is considered mature [16]. Several 
projects exist allowing security researchers to employ attack trees for formalized red-team 
brainstorming and prioritizing system weaknesses, including ADTool [17], AttackTree [18], 
and SeaMonster [19]. 

In a typical attack tree, a goal G is related to a set of subgoals, 5i,..., sj, each represented 
as nodes in a directed graph (see Figure 3.1). To achieve goal G, an attacker must satisfy 
its subgoal dependencies. When two subgoals must both be satisfied to achieve the goal, 
its edges are labeled with a boolean “and” expression to express this dependency. Unless 
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otherwise noted, edges represent subgoals in an “or” relationship, where satisfying any 
subgoal achieves the goal. We denote an edge connecting goals G and dependency subgoal 
Si as G ^ Si. 



Figure 3.1: A simple attack tree, showing the relationship between goals and 
subgoals. 


Figure 3.1 is a representation of a small attack tree. In a larger tree, each subgoal Si may 
have subgoals itself, modeled as the children of node Si, and so on. When the attack tree is 
complete, the objective G can be achieved by finding a set of paths from the leaves to the 
root, while satisfying the boolean restrictions attached to the edges involved in that path. 
In the remainder of our work, we do not utilize any “and” edges in our attack trees and all 
subgoals are in an “or” relationship. Thus, for this case, accomplishing G is equivalent to 
following a path from any leaf to G. 

Consider the following example proposed by Schneier [16]. A thief wishes to access a 
3-hour safe (G). The thief can pick the lock ( 51 ), use a blow torch to cut into the safe ( 52 ) or 
guess the combination ( 53 ). Achieving any of these subgoals is sufficient to achieve the goal 
G, but each have different costs, in terms of money, time, skill, etc. Attaining each subgoal 
may, itself, incur some prerequisites (e.g., buying the blowtorch), which can be modeled as 
further subgoals. 

In order to characterize the relative security of the system, one can annotate the nodes of 
the tree to support attack cost-analysis. These annotations may represent the time or money 
required to achieve a subgoal. The values assigned to nodes are not limited in any fashion: 
one can assign a value indicating probability of attack success, level of attack complexity, 
pre-requisite skills or required equipment [16]. These values allow for flexible reasoning 
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about the security of the system. With these annotations, one can use the attack tree to 
reason about which attack may be launched with the highest probability of success and the 
lowest complexity, or the analysis of which attack is the cheapest [16]. We refer the reader 
to Schneier for further explanation of the utility of attack tree methodology for modeling 
computer systems [16]. 

When calculating the cost to execute a successful attack against the system in question, 
one must make some assumptions about the adversary potentially performing the attack. 
In this work, we assume the adversary is capable of utilizing any attack path and will 
choose the path with the minimum cost. Thus, no subgoal is impossible to achieve and we 
consider all node annotations to characterize cost, in some sense. We denote the cost to 
reach node x as Cost(x). Given edge x ^ ?/, the cost to achieve goal x using subgoal y 
is Cost(x ^ y). In many cases, Cost(jc y) = Cost(y). Consider, however, our prior 
example: if cost is dollars, y is “renting a blowtorch for an hour,” x is “attacking a 3-hour 
safe” and Cost(i/) = $100, then it may be the case that Cost(x y) = $300. To calculate 
the minimum cost to the attacker for achieving G, we consider the minimum cost attack 
terminating at G: 

Cost(G) = min{Cost(G ^ sj)}. (3.1) 

j 

For example, in Figure 3.2 we show that the lowest cost associated with any of the attack 
paths from the subgoals of G is Cost(G ^ vi). As a result, we have propagated that value, 
in this case 20, to Cost(G). We can apply this procedure for calculating costs from the 
leaves of a completed tree all the way to the root to arrive at the overall cost to break the 
system. 
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Figure 3.2: An attack tree with cost annotations. 


3.2 Attack Trees with Reductions 

We expand traditional attack trees, allowing a node to be annotated with an arbitrary set of 
parameters and an edge to be associated with a set of reductions (see Figure 3.3). 



Figure 3.3: Reductions as relations between variables associated with sub¬ 
goals. 


Let node s be associated with the set of free variables Var^, which can be partitioned 
into two types: security parameters (Param^) and cost parameters (Cost^). For example, 
p 6 Param^ c Var^ may be a variable characterizing key length and r 6 Cost^ c Var^ 
may be a variable related to time complexity. Every variable cr 6 Var^ has an associated 
domain Dom(cr) over which this free variable ranges and, given any finite set of values in 
this domain, the minimum and maximum are well-defined. Edge g ^ s may be annotated 
with a reduction r. A reduction r is a group of relations among Var^ and Var^: 

r = fc7s7 rp7rim, 47ram} whcrc r^^^t is a relation / : Var, ^ Cost^ 
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For example, is a relation expressing cost, in terms of variables from Cost^, to achieve 
g by employing subroutine s and instantiating its variables Var^. 

Reduction r can be interpreted as a guarantee that an adversary, given a subroutine solving 
5, will incur a cost greater than or equal to some guaranteed minimum cost (GMC) to solve 
g. We define the GMC indicated by reduction r when subroutine s is instantiated with 
variables p as: 

GMCr\p) = rtTJ(P) (3-2) 

Returning to our prior example, consider an experiment to determine the minimum time to 
access a particular safe with a blow torch. The analysts are given some characteristics p 
for the blow torch (e.g., it uses acetylene gas, burns at 6000°F). The experiment predicts a 
conservative lower-bound for attack time to be at least two hours. The experiment is a type 
of reduction, specific to that goal (g), employing a general attack using a blowtorch (s) in 
the context of that torch’s parameters (p) yielding two hours as the GMC. 

As a result of ongoing efforts to improve or tighten security reductions, there may be several 
reductions relating subgoals (see Figure 3.4). Returning to our example, this is analogous to 
new experiments yielding improved bounds on the time to open the safe with the blowtorch, 
finding it takes at least three hours based on a more careful analysis, rather than at least two 
hours. We note that had experiments revealed that the safe could be opened in one hour 
using the blowtorch, this would not be a tighter reduction but, in fact, a refutation of the 
prior reduction, demonstrating it to have been unsound. In our model, we assume all our 
reductions are mathematically correct and sound. 



Figure 3.4: Each reduction yields a different relation, and may yield a differ¬ 
ent GMC. 
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3.2.1 Propagating Values “Up” the Tree 

Let R{g, s) = {ri,.. .,r,} be the set of all reduetions relating ^ to g. Each reduction r, 
may yield a different GMC under conditions p 6 Var^, yielding different relations for cost 
(see Figure 3.4). Given multiple reductions yielding different GMCs, we must determine 
which GMC to utilize in determining the cost along that particular attack path. Assuming all 
reductions are sound, the greatest lower bound (infimum) yields the overall GMC expressing 
cost for edge g ^ 5. The cost to achieve goal ^ via the attack path using subgoal ^ is therefore 
the maximum over all GMCs for reductions relating s to the cost of solving g: 

GMC(^ ^ s)= max (GMC^^") (3.3) 

i 

In order to calculate the cost of achieving G when dealing with multiple attack paths to G, 
one must first determine the GMCs of each reduction relating each subgoal to the goal (from 
Equation 3.2). Then, the cost along each attack path is resolved by taking the maximum 
along that path (from Equation 3.3). Finally, we determine the cost to achieve G (from 
Equation 3.1). 

For example, consider the example tree from Figure 3.5 and its related information from 
Figure 3.6. 



Figure 3.5: A simple attack tree, showing multiple reductions. 
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• S.t 6 Costi c Var^, a variable related to time complexity 

• u.t 6 Cost„ c Varj(, a variable related to time complexity 

• g.t & Cost^ c Var^, a variable related to time complexity 

• ri has relation s.t < 2^^ x g.t’ 

• r 2 has relation s.t <2^^ x g.t^ 

• Vu has relation u.t = 2x g.t 

Figure 3.6: Symbols and relations for the tree in Figure 3.5. 

If we find that s.t = 2^*^, r\ yields g.t > 2^® and ra yields g.t > 2^*^. So, reduction r\ states 
that goal g is secure against an adversary running in time < 2^® while reduction r 2 states that 
goal g is secure against an adversary running in time < 2^®. We choose the value yielded 
by reduction r 2 (applying Equation 3.2) because it makes the stronger security claim. We 
then can say that the cost to achieve goal g via the attack path using subgoal 5 is 2^®. If 
we find u.t = 2^®, yields g.t = 2^^. So, we apply Equation 3.1 to determine the cost to 
achieve goal g = 2^^. 


3.2.2 Propagating Values “Down” the Tree 

Thus far, we have discussed and given examples of propagating values “up” the attack tree, 
from subgoals to goals. We now discuss propagating values “down” the attack tree from 
goals to subgoals. There are differences that surface when propagating values “down” the 
tree. These differences are mainly in how security parameters and costs are reduced between 
two nodes and how we choose which values will get propagated into a node from its edges. 

When traversing down the tree, instead of employing the guaranteed minimum cost, we 
employ the guaranteed peak cost (GPC). The GPC characterizes the smallest security 
parameters guaranteeing some lower-bound cost on attacker effort. Given t 6 Cost^, we 
define GPC as: 

GPCr'CO = 47rL(t) = P 6 Param, (3.4) 

When dealing with multiple reductions, each will produce a lower-bound on the time for 
attacker effort. Assuming all reductions are sound, the least upper bound (supremum) yields 
the smallest guaranteed attack cost for g given the ability to solve 5. The cost to parameters 
to employ g via the attack path using subgoal s is therefore the minimum over all GPCs for 
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reductions relating g to the cost of solving s: 


GPC(g s)= min (GPCff") 

i ’’ 


(3.5) 


Again, consider the example tree in Figure 3.5 and related information from Figure 3.6. If 
we are given g.t = 2^0 , r\ yields s.t < 2^^^ and r 2 yields s.t < 2^^®. So, reduction r\ states 
that, given an adversary breaking g in time 2^® then there exists an adversary breaking s in 
time < 2^^^, while reduction r 2 states that, under the same condition, there is an adversary 
breaking s in time < 2^^®. We choose the value yielded by reduction r 2 because is portrays 
the tighter bound and represents the stronger adversarial ability. We can then resolve these 
two reductions and claim the cost to achieve subgoal s = 2^^®, when given an adversary 
against g running in time 2^®. The reduction Vu yields u.t = 2^^ Since there is only one 
reduction between goal g and subgoal u, we can say the cost to achieve subgoal u = 2^^. 
Thus, to achieve an effective security of 2^® for g, we must select parameters forcing s to 
have effective security of at least 2^^® and forcing u to have effective security 2^^ 


3.3 Case Study: The Schnorr Signature Scheme 

To express these ideas in the context of a non-trivial case study, we consider the Schnorr 
public-key signature scheme, with known relevant attacks and reductions. We selected this 
target scheme because it has the ability to demonstrate a variety of the features previously 
discussed for our methodology. In particular, the Schnorr signature scheme presents us the 
opportunity to reason about multiple reductions, given the original reduction presented by 
Schnorr [20] and the tighter reduction by Pointcheval and Stern [7]. It also allows us to 
demonstrate the situation where multiple attack subgoals must be analyzed, and subgoals 
are re-used within the tree in different contexts. 

Employing the notation introduced thus far, we can express pictorially the attack tree for 
our Schnorr case study, annotated with variables and reductions (see Figure 3.7). The root, 
Schnorr Signature, represents a generic, high-level goal to break some aspect of the signature 
scheme. There are several notions of security applicable to the signature schemes— 
e.g., security against no-message attacks, security against chosen-message attacks—each 
yielding different trees. We have chosen to analyze one notion of security, existential forgery 
under an adaptively chosen-message attack (EF-ACMA). 
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Schnorr Signature 
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Figure 3.7: The Schnorr signature scheme attack tree. Nodes (black boxes) 
represent subgoals and edges (green lines) are annotated with reductions 
(green dots). 


The subgoal of Break EF-ACMA is Break Subgroup Discrete Log Problem. The relationship 
between these goals are provided by two proofs: S89, the reduetion originally provided 
Sehnorr [20]; and PSOO, the reduetion provided by Pointeheval and Stern [7]. This is an 
example of the seenario diseussed in Seetion 3.2. In this ease, PSOO provides the tighter 
bounds, improving a query bound from 0{q^) to 0{q). 

The Break Subgroup Discrete Log Problem has two subgoals: an attaek via Pollard’s Rho 
and reduetion to a related problem. Break Discrete Log Problem. The Break Discrete Log 
Problem goal has subgoals, most of whieh are attaeks or generalizations of attaeks. One 
attaek is, again, Pollard’s Rho, demonstrating how a goal and its subgoals may share a 
eommon leaf. 

The leaves in the tree eaeh represent an attaek, employing a speeifie algorithm to attaek 
the properties of a goal. These are annotated with both variables and relations. Very 
general attaeks like Exhaustive Search ean be applied direetly to most subgoals, but we 
omit those edges for brevity and elarity. The interested reader is referred to the following 
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resources for details on the attack nodes in this case study: Pollard’s Rho algorithm [21], 
Shank’s Baby-step Giant-step algorithm [22] and the general number field sieve (GNFS) 
algorithm [23]. 
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CHAPTER 4: 

Concept of Operations and Design 


In this chapter we discuss concept of operations of our software tool to include propagating 
values in both directions, described briefly in Section 3.2. We discuss target features for 
our software tool and a high-level design supporting extensibility and modularity. 


4.1 Concept of Operations 

In its simplest use, our software tool should be capable of resolving two types of questions: 

1. Given some set of security parameters (e.g., n, p and q), what effective security is 
provided? 

2. For a desired target effective security, what security parameters should be used? 

In the former case, the user provides n, p, and q and the tool returns the effective security 
A. In the latter case, the user provides a target effective security A and the program returns 
a set of satisfying parameters n, p and q. 

Being able to re-run the above analyses enables interesting counter-factual analyses for 
prioritizing new research. This would enable us to pose questions, like, would improving 
the tightness bounds of this proof effectively strengthen the security of the scheme, or does 
some other factor create a bottleneck? 

To illustrate the possible operation of the analysis engine consider our case study as an 
example (see Section 3.3). The user may desire to calculate the security parameters required 
to achieve a target level of effective security for the EF-ACMA property for the Schnorr 
signature scheme. The level of effective security can be expressed in terms of a lower- 
bound time required to break this property. Thus, the user provides some target value, like 
^EF-ACMA = 2^®, as the time budget within which no adversary can break EF-ACMA. In 
response, the user expects the tool to provide recommended values of security parameters, 
such as p (the size of the prime-order group) and q (the size of the subgroup) for the scheme. 
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To accomplish this task, the analysis engine propagates the eost values down the tree as 
diseussed in Seetion 3.2.2. The desired eost of tsF-ACMA = 2^® is passed through the two 
relations in the reduetions leading to the subgoal Break Subgroup Discrete Log Problem 
(see Figure 3.7) to determine their GPCs as in the example provided in Seetion 3.2.2. The 
eost of Break Subgroup Discrete Log Problem is then determined utilizing the equations 
given in Chapter 3. In this case we derive tsDL = 2^^^ This proeedure is then repeated 
to determine the eosts for the subgoals of Break Subgroup Discrete Log Problem. For 
simplicity we opt not to step through eaeh ealeulation down the tree. This proeess eontinues 
until we have propagated all cost values to each node from EF-ACMA to each of the leaves 
shown in Figure 3.7. We reeall from Seetion 3.3 that eaeh of these nodes is a generalized 
attaek. 

It is in these leaf nodes (attacks) where the eost value is direetly translated into a seeurity 
parameter that requires an attaeker to undergo a particular cost. In other words, the leaf node 
reduees to no other problem. In our example, we have now populated the value tpR = 2^^^ 
into the Pollard’s Rho attaek. We can now utilize the approximation tpR = -^npR to eonelude 
npR = 2^^^. This ean be done for all leaf nodes. 

Now that we have values for eaeh seeurity parameter in eaeh leaf node, we can propagate 
those values up the tree as deseribed in Section 3.2.1. Again, we opt not to step through 
every ealeulation. The user now has aeeess to the value of every possible security parameter 
for every node in the attaek tree that would make it impossible for an adversary to break the 
EF-ACMA property within the 2^^ budget given. For instanee, the user can now see that 
p = 2354. 

This example exhibits the need to make two passes through the tree (up and down) in order 
to provide values for parameters when given a target effeetive seeurity. The process is 
also neeessary when the analysis engine provides the effeetive seeurity when given a set of 
seeurity parameters. 


4.2 Design Goals 

Our software tool should reason about maehine-readable proofs and attaek metadata, to 
provide aeeurate eonelusions regarding the relationship between seeurity parameters and 
effeetive seeurity. In addition, our software tool should be both modular and extensible. 
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Modularity allows expertise from one domain (e.g., using the general number field sieve to 
perform attacks against a cryptosystem) to be combined with that of another domain (e.g., 
the state of attacks against a particular hash function). It should be possible to develop 
modules independently, each defining their own symbols, cost parameters and relations. A 
new system employing both number-theoretic assumptions and hash functions may, then, 
employ these modules to reason about complex schemes. It should be possible to extend 
the tool, to incorporate new reductions, new objectives and new attacks. An extensible 
design allows organizations to incorporate new information for prompt, informed reactions 
to newly published attacks. 

4.3 Software Design 

We identify two base classes, related directly to our use of attack trees for reasoning about 
data: the AttackEdge and AttackNode classes. Figure 4.1 is a detail of the AttackEdge 
base class and its subclasses. Figure 4.2 is a detail of the AttackNode base class and its 
subclasses. 

4.3.1 Attack Edges 

The AttackEdge class represents the edge in a directed graph, and has an attribute named 
parent and child representing the nodes it connects. Each of these attributes reference 
an appropriate AttackNode class instance (see Section 4.3.2). Reduction is a subclass of 
AttackEdge, representing an edge annotated with a reduction. The Reduction subclass has 
a number of attributes: full_name is intended to be assigned a string that describes the 
reduction; expr lists the expressions describing how values are mapped between the goal 
and subgoal; symbols_list lists the symbols used in the reduction; conservative_substitutions 
lists a set of conservative substitutions for potential free variables in the reduction. 
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Figure 4.1: UML diagram for the AttackEdge class. 


The remaining classes in Figure 4.1 are example subclasses of the Reduction class containing 
metadata specific to our case study. For example, PSOO is the Pointcheval and Stern reduction 
between Break EF-ACMA and Break Subgroup Discrete Log Problem. DlPr is the reduction 
between Break Discrete Log Problem and Pollard’s Rho. 

4.3.2 Attack Nodes 

The AttackNode base class has the full_name and symbolsjist attributes, and they serve the 
same role as in the AttackEdge class. Our attack tree manages two types of nodes: Objective 
nodes and Attack nodes. All Attack nodes are leaf nodes, i.e., do not have children. All 
Objective nodes represent an objective or subgoal, such as “solving the discrete log problem.” 
An Objective node may have one or more children (of any AttackNode type) and one or 
more parents (of Objective node type). 
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Figure 4.2: UML diagram for the AttackNode class. 


The Attack class has the attribute expr, a list containing one or more expressions relating 
cost parameters and security parameters. An example of an expression contained within 
the expr list is Tpr = ^fn from the Pollard’s Rho node in Figure 3.7. In comparison, the 
Objective class has the attribute constraints, a list of zero or more expressions describing 
any constraints on the symbols within the objective. For example, in our Schnorr case study, 
the Break Subgroup Discrete Log Problem node employs the constraint q < p, expressing 
that the order of the subgroup q must be less than the order of the group p. 
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CHAPTER 5: 

mplementation 


In this chapter we discuss how our software tool and its routines are implemented. In 
Sections 5.1-5.4, we introduce notation and describe the routines for our analysis engine. In 
Section 5.5, we discuss the software implementation of this analysis engine. In Section 5.6, 
we provide sample analyses, compared with existing guidance. 


5.1 Notation 

The pseudocode expressing the algorithms for building and maintaining our data structures 
employs the following notation. 

Graph Notation. Each graph G = (N, E) is a directed, acyclic multigraph. We let E{G) 
denote the edge multiset and N{G) denote the node set. 

Nodes. There are two distinct types of nodes. Objective nodes and Attack nodes (see 
Section 4.3.2). We let 0{G) denote the set of Objective nodes and J3l(G) denote the 
set of Attack nodes, where N{G) = 0{G) (J Jl(G) and 0(G) H ~9l(G) = 0 
Edges. We let 'R(G) denote the set of reductions associated with G. Every edge is annotated 
with a reduction, so \E(G)\ = |!R(G)|. Eor e e E(G), we let ji(e) 6 'R(G) be the 
reduction associated with edge e. Alternative notation for edge e = (x, y) and its 

r 

reduction r = %(e) include x ^ y, x ^ y and r(x, y). 

Predecessor and Successor. Given edge x ^ y e E(G), we say .r is an immediate 
predecessor (parent) of y, and y is an immediate successor (child) of x. Eor edge e = 
(x, y), we denote .r = e.parent and y = e.child. Similarly, we denote .r 6 y.parents 
for the set of immediate predecessors and y 6 .r.children for the set of immediate 
successors. More generally, we say n, is a predecessor of nj if there exists a series of 
edges Hi tii+i, rii+i n,+ 2 , ..., ny-i ^ nj connecting n,- to nj. By definition, if 
Hi is a predecessor of nj, then Uj is a successor of n/. 

Symbols. Eor v: 6 'R(G) (J 0(G) (J Ji(G), x has an attribute .r.symbols. This is a list of 
symbols associated with the node (see Section 4.3.1 and Section 4.3.2). The variant at¬ 
tribute .r.symbols^^^f and v:.symbolSp^^„„ selects the symbols from v:.symbols that are 
cost or security parameter symbols, respectively. Eor different nodes n A m, symbols 
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are unambiguous, i.e., m.symbols H n.symbols = 0. For any reduction x ^ y, sym¬ 
bols are consistent with adjacent nodes, i.e., r.symbols c ;c.symbols IJ «/.symbols. 

Relations. For .r 6 *R(G) U 0(G) IJ ^(G), x has an attribute .^.relations. This is a list 
of formulae expressed in terms of constants, relations and symbols in jc.symbols. 
When X 6 0(G), ^.relations is synonymous with the x.constraints attribute (see Sec¬ 
tion 4.3.2). When x 6 'R(G) (J J3l(G), ^.relations is synonymous with x.expressions 
attribute (see Section 4.3.1 and Section 4.3.2). 

Values. For x 6 0(G) (J Jl(G), x has an attribute x.values. This is a list of values associ¬ 
ated with X. symbols. Initially, this list has no values, i.e., x. values = {(5, -L)| for s 6 
X. symbols}. When a value for symbol 5 is derived, then (s, v) 6 x. values and 5 is no 
longer considered a free symbol. 

Expressions. Each expression x has a number of attributes and support functions. The 
attribute x.free_symbols yields the set of free symbols in expression x. The function 
x.substitute(5, s') syntactically replaces the symbol s with symbol s'. The function 
x.solve(5) solves expression x for the value for free symbol s. 

Assignment. In our pseudocode, x <— «/ is the assignment operator and modifies the 
original object x. For lists, we abuse this notation to denote both insertion and 
update, depending on context. For example if S <— 0, then S (x,y) updates the 
list to be 5 = {(x, y)}. Subsequent insertions with related tuples, e.g., S <— (x, y') 
and S (x', y"), update the list to be S = {(x, y'), (x', y")}. 


5.2 Overview 

Our software tool first builds the Master Graph G of reductions and the objectives defined 
in its database. Given a target objective ctq, we prepare the data structure used for analysis, 
called the Traceback Graph, using the following steps: 

1. Given target objective ctq e 0(G), derive the subgraph of G comprised of ctq is its 
successors to form IV, the Working Graph (see Figure 5.1). 

2. Using W, initialize T, the Traceback Graph (see Figure 5.2). 

3. Normalize T so that it has a tree structure, by duplicating those subtrees with multiple 
parents (see Figure 5.3). 


24 



1: function SuBGRAPH(graph G, target ctq g 0(G)) 

2: graph W <— (0,0) 

3: for all n g N(G) where (tq g ^.parents do 

4; add n to N(W) 

5: for all e g E(G) where e = (n, n') do 

6: add e to E(W) 

7: end for 

8 ; end for 

9; return W 

10: end function 

Figure 5.1: Pseudocode for the Subgraph function. 

1: function iNixTRACEBACKfgraph VF) 

2: graph T <^W 

3: forallx 6!R(r)U<5(r)do 

4: A.values 0 

5: for all 5 e a. symbols do 

6: X.values <— (s, ±) 

7: end for 

8 : end for 

9: return T 

10: end function 

Figure 5.2: Pseudocode for the InitTraceback function. 

1: function NoRMALizETRACEBACKfgraph T, target (Tq 6 0(G)) 

2: for n G N(T) where |n.parents| > 1 and depthfn, cro) is max over N(T) do 

3: J I«.parents I 

4: remove n from N(T) 

5: create d copies of n and its successors to produce subtrees p\,...,pd 

6: addpi,.. to r 

7: modify all edges (xi, n) G E(T), so that the /-th edge is (xi,pi) 

8: r NORMALIZE(r) 

9: end for 

10: return tree T with root ctq 

11: end function 

Figure 5.3: Pseudocode for the NormalizeTraceback function. 


The Traceback Graph is used to hold values associated with the symbols for objectives and 
reductions in the Working Graph, derived as we traverse up or down the attack tree. For the 
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Master Graph and Working Graph, it is possible for a node to have multiple parents. Thus, 
before normalization, traversing down the Traceback Graph might eause nodes to be visited 
twiee, via entirely different parents. Sinee derived values will be based on attributes of both 
parent and ehild, it would be ineorreet to diseard or update a value based on information 
from an unrelated parent. Thus, the Traceback Graph is normalized to form a tree, ensuring 
eaeh node has only one parent. This is aeeomplished by duplieating subtrees that would 
otherwise be re-visited. After normalization, the Traceback Graph has the same number of 
edges as the Working Graph and is strueturally identieal to traversing the Working Graph in 
depth-first order. As an added benefit, the intermediate values generated as expressions and 
eonstraints are proeessed elosely follows walking the Working Graph. Thus, the Traceback 
Graph allows one to “traee baek” the symbols resolved and values derived at eaeh step of 
walking the graph. 

At this point, the attaek tree is prepared for analysis. Analysis solves for either effeetive 
seeurity (in terms of cost) or settings (in terms of security parameters) needed to achieve 
a particular level of security (see Section 4.1). For example, if a user wants to solve for 
the cost to break the objective, the user will provide the security parameters for the scheme 
as input. Since we must propagate values in both directions within our attack tree (see 
Section 4.1), analysis is a two-pass process. PhaseOne derives values from the root to the 
leaves, and PhaseTwo from the leaves to the root. 

1. The user selects target symbols related to objective (Tq, placing these in the global 
SOLVE list. 

2. The user builds K, a set of known values for other parameters related to ctq. 

3. We build traverseList, the list of r e P.{T), in depth-first order starting at ctq. 

4. PhaseOne: we utilize Reductions in T to populate values down the tree, where we 
will use the expressions in the Attack nodes to derive the values needed for analysis 
and save these in T (see Figure 5.4). 

5. PhaseTwo: we utilize values stored in T during the first pass to solve for remaining 
free variables (see Figure 5.11). 

6. If successful, a value {s, v) 6 ctq. values will exist for any symbol 5 e SOLVE. 

In the following sections, we elaborate on PhaseOne and PhaseTwo and the routines sup¬ 
porting these. 
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5.3 First Pass 

During PhaseOne, we populate-down values from the root the leaves (see Figure 5.4). We 
begin by moving known values from K into root (Tq. 

1; function PHASEONE(tree T with root ctq, known values K, traverseList) 

2: for (s, v) e K where 5 6 o-q. symbols and (s, J.) 6 (Tq. values do 

3: CTo.values <— (s, v) 

4: end for 

5: for r(cri, CTj) e traverseList do 

6: r <— PopuLATEKNOWNs(cr/, r) 

7: r <— REMOVEFREE(r.values, r) 

8: if cTj 6 ^(T) then 

9: cry RemoveFreeCp. values, (Ty) 

10; else if cry 6 0(T) then 

11; if there are multiple edges for (cr,, aj) then 

12; CTj <— RESOLVEMuLTiEDGE(r.values, cry, cr,) 

13; else 

14; cry <— RESOLVE0BJECTIVE(r. values, cry) 

15; end if 

16; end if 

17; end for 

18; return T 

19; end function 

Figure 5.4: Pseudocode for PhaseOne. 


We visit each edge in depth-first order, populating known values, using expressions to derive 
more known values, simplifying expressions and populating values to adjacent objectives. 
At each edge, values are populated from parent to edge (see Figure 5.5), changing these 
according to their symbol type. 

Next, known values at edges are substituted into expressions, following the same process 
employed at attack nodes, i.e., leaves (see Figure 5.6). If there are enough known values 
to eliminate all but one free symbol, we will have effectively determined a value for that 
symbol. We can solve for the free variable and store the value. 
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1; function PopuLATEKNOwNs(node cr, r e ^{T)) 

2: for {s,v) 6 cr.values and 5 6 cr.symbols H r.symbols do 

3: if PhaseOne then 

4: r.values {s, v) 6 cr.values 

5: else if ( 5 , v') e cr.values and 5 6 cr.symbols^^^j and v < v' then 

6: r.values {s, v) 6 cr.values 

7: else if is,v') e cr.values and 5 e cr.symbols^^^^^ and v > v' then 

8: r.values {s, v) 6 cr.values 

9: end if 

10 ; end for 

11: return r 

12 ; end function 

Figure 5.5: Pseudocode for the PopulateKnowns function. 


1; function REMOvEFREE(t)a/5, p 6 'R(r) IJ 
2: for expr in ju.relations do 

3; for ( 5 , v) 6 vals where 5 6 eAjur.free_symbols do 

4: expr <— eA;?r.substitute(5, v) 

5: end for 

6: if 5 G cA;?r.free_symbols and |eApr.free_symbols| == 1 then 

7: value <— ADVANTAGINGSuBSTITUTION(cAj!?r, s) 

8; if PhaseOne and p g !R(r) and 5 ^ SOLVE then 

9; p.values <— ( 5 , value) 

10; else if (PhaseOne and p g or PhaseTwo then 

11: ju. values <— {s, value) 

12: end if 

13: else if G 'R(r) then 

14; p <— CoNSERVATivESuBSTiTUTiON(eA;?r.free_symbols, ju) 

15: if a new value was just uncovered by the previous step then 

16: p <— REMOVEpREEfr, Vals, p) 

17: end if 

18: else if P G Jl(T) then 

19: error > analysis fails if attack nodes have too many free variables 

20 : end if 

21 : end for 

22 : return p 

23: end function 

Figure 5.6: Pseudocode for the RemoveFree function. 
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The process for removing a free variable involves deriving values for symbols based on re¬ 
lationships in reductions (see Figure 5.7) and employing conservative symbol substitutions 
(see Figure 5.8). 

1; function ADVANTAGiNGSuBSTiTUTiON(re/aizon, symbol) 

2: if relation is “=” then 

3: exp <— relation 

4: else if relation is either “<” or “>” then 

5: exp <— GreaterSide(eAp) = (LesserSide(cAp) -i-1) 

6: else if relation is either “<” or “>” then 

7: exp <— GreaterSide(eAp) = LesserSide(cjcp) 

8 : end if 

9: value exp.so\\e{s ymbol) 

10; return value 

11 ; end function 

Figure 5.7: Pseudocode for the AdvantagingSubstitution function. 


1; function CoNSERVATivESuBSTiTUTiON(/ree_5 r 6 ^(T)) 

2; if PhaseOne then > during PhaseOne 

3; cr r.child 

4; else > during PhaseTwo 

5; cr r.parent 

6 ; end if 

7; if cr.symbols H free_symbols 0 then 

8; for expr 6 r.conservative_substitutions do 

9; for (s,v) 6 r.values where 5 6 eApr.free_symbols do 

10; expr <— eApr.substitute(5, v) 

11; end for 

12; if 5 6 cApr.free_symbols and |eApr.free_symbols| == 1 then 

13; value <— AoVANTAGINGSuBSTITUTIONfcApr, s) 

14; r.values (s, value) 

15; end if 

16; end for 

17; end if 

18; return r 

19; end function 

Figure 5.8: Pseudocode for the ConservativeSubstitution function. 


Conservative substitutions are “safe” substitutions based on bounds, selecting parameters 


29 





that most advantage the adversary. This is often required when reductions employ under¬ 
constrained expressions or when free symbols have a bound but no known parameter 
(discussed in Section 4.3.1). Similar rationale is employed when deriving new values based 
on relations, re-arranging equations and selecting bounds that most advantage the adversary. 

Next, after edge expressions are simplified and new values have been derived, we populate 
down values to child nodes (see Figure 5.9). The values stored at the objective node are 
updated, depending on the type of symbol. If the symbol represents a cost variable, the 
edge value updates the value if it is smaller, i.e., the adversary cost is smaller using the 
new edge. The opposite is true for security parameters, i.e., the new edge implies a larger 
parameter is required. 

1; function RESOLVE0BJECTivE(ya/5, cr e 0(T)) 

2 : for {s, v) G vals where 5 g cr.symbols do 

3: if ( 5 , -L) G cr.values then 

4; cr.values <— (s, v) 

5; else if (5, v') g cr.values and g cr.symbols^^^f v < v' then 

6: cr.values <— ( 5 , v) 

7: else if is,v') g cr.values and g cr.symbols^^^^^ and v > v' then 

8: cr.values <— {s, v) 

9: end if 

10 : end for 

11: returner 

12 : end function 

Figure 5.9: Pseudocode for the ResolveObJective function. 


For the case when multiple edges exist, i.e., due to multiple reductions, populating values 
down to the child node requires modification, as potential values populated at the node 
must be withheld until all reductions are processed (see Figure 5.10). The new values from 
each edge are held temporarily, this multi-edge value group is managed analogously to how 
values are updated at the child, before they are populated to the child. When the final edge 
is processed, the values are resolved as normal. 
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function RESOLVEMuLTiEDGE(f;a/5, cri, 0 - 2 ) 
if this is the first (cri, 0 - 2 ) edge processed then 

cri.mvals[cr 2 ] <— 0 > holds values for edges between cri and 0-2 

cri.count[cr 2 ] total number of edges between (cri, cr 2 ) 

end if 

let multv = cri .mvals[cr 2 ] > an alias, for notational convenience 

let count = CTi .count[cr 2 ] > an alias, for notational convenience 

> now, process one edge, i.e., associated with the reduction annotated with vals 
count <— count - 1 

for (5, v) 6 vals where 5 e cri.symbols do 

if PhaseOne then > during PhaseOne 

if (5, -L) 6 multv then 
multv <— (s, v) 

else if (s, v') e multv and 5 6 
multv <— (5, v) 

else if ( 5 , v') 6 multv and 5 6 
multv <— (5, v) 

end if 
else 

if ( 5 , -L) 6 multv then 
multv <— (5, v) 

else if ( 5 , v') e multv and 5 e 
multv <— (5, v) 

else if ( 5 , v') e multv and 5 e 
multv <— (5, v) 

end if 
end if 
end for 

if count == 0 then > this was, in fact, the last edge 

(Ti RESOLVE0BJECTIVE(mM/ii;, (Ti) 

end if 
return cri 
end function 

Figure 5.10: Pseudocode for the ResolveMultiEdge function. 


cri .symbols^^^j and v < v' then 
cri .symbolSpa^a^ and v > v' then 

> during PhaseTwo 

cri .symbols^^^j and v > v' then 
cri .symbolSp^^^^ and v < v' then 


5.4 Second Pass 

After our first, top-to-bottom pass where values are populated across the tree, a bottom-to- 
top pass is performed (see Figure 5.11). This PhaseTwo pass is similar to PhaseOne and 
utilizes the same support routines. To traverse back up the attack tree, we re-visit edges in 
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reverse order. 


1; function PHASETwo(tree T, traverseList) 

2: for r(cr,-, (Tj) 6 XQ\Qxsc{tr averse List) do 

3: if (Tj 6 0{T) then 

4: r PopuLATEKNOWNs(cry, r) 

5; end if 

6: r REMOVEFREE(r.values, r) 

7; if there are multiple edges for (cr,, cry) then 

8; (Ti RESOLVEMuLTlEDGE(r.values, Cr,', (Tj) 

9; else 

10 ; (Ti <— RESOLVE0BJECTivE(r.values, n/) 

11 : end if 

12 : for expr 6 r.relations do 

13: for (s, v) 6 r.values where 6 e.x:pr.free_symbols do 

14: expr <— e.rpr.substitute(5, v) 

15: end for 

16: end for 

17: end for 

18: return T 

19; end function 

Figure 5.11: Pseudocode for PhaseTwo. 


Attack nodes should now be fully populated with values, and those values can be popu¬ 
lated up the tree from child to parent. Values for objectives and multi-edges are resolved 
analogously to prior logic. As described in Section 3.2, walking up the tree in the presence 
of multiple reductions requires slightly different logic: assuming all reductions are sound, 
when the parent’s cost is determined to be greater, we consider this to be a tighter proof and 
select the more accurate result (with analogous reasoning when the more accurate reduction 
allows us to select a smaller security parameter). 

5.5 Python Implementation 

We implement our software tool in the Python programming language version 3.5.1 [24] 
using the Anaconda package and environment manager [25]. We select Python because it 
is open source, widely used and relatively accessible, all of which support the extensibility 
goals of our software tool. To implement our attack tree data structures, we employ the 
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NetworkX Python module version 1.11 [26]. Of interest to us, NetworkX supports direeted, 
multi-graphs and provides support funetions to iterate through graph components, to assign 
and manage data associated with nodes and edges, to traverse graphs and to export graphs 
to formats usable by graph visualization software. To manipulate expressions associated 
with objectives, attacks and reductions, we employ the Sympy Python module [27]. This 
provides support for expression re-writing and symbolic solving. 


5.6 Case Study: The Schnorr Signature Scheme 


We validate our software tool using the Schnorr case study introduced in Section 3.3. 
Figure 5.12 is a graphical representation of the tree—its objectives, reductions and attacks— 
comparable to Figure 3.7. The software producing this visualization does not draw explicit 
multi-edges, and represents edge direction using line thickness rather than arrow heads. 

EF-ACMA of the Si igital Signature Scheme 


Subgroup Disc Problem 




Shank's Baby-; iant-step attack 




^huosiive ^arch Attack 


Figure 5.12: Graph for the Schnorr case study, generated by our software 
tool. 
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We consider two analysis cases in the context of this case study, both employing the target 
objective Break EF-ACMA for cro, the root of our analysis tree. 

Case 1. We supply our software tool with a set of security parameters and use it to solve for 
the cost to break the Schnorr scheme in the EF-ACMA sense. This requires setting 
(i) SOLVE to include the relevant time parameter for ctq and (ii) known values that 
include relevant security parameters for ctq. We are essentially asking the question 
“what is the effective security for EF-ACMA with the Schnorr signature scheme using 
the chosen security parameters?” 

Case 2. We supply our software tool with a set of cost parameters and use it to solve for 
security parameters for the Schnorr scheme. This requires setting (i) SOLVE with 
relevant security parameters and (ii) known values that include 2^ as the target time- 
cost parameter. We are essentially asking “under what parameters will the Schnorr 
signature scheme achieve an effective security of 2^ for EF-ACMA?” 

The full list of symbols associated with attacks and objectives in the subgraph associated 
with components connected to ctq is given in Figure 5.13. 
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Symbols for node Exhaustive Search Attack 


Es.n: Keylength 

Es.t: Time 


Symbols for node Shank's Baby-step Giant-step attack 

BsGs.n: Keylength 

BsGs.t: Time 


Symbols for node Discrete Log Problem 

Dl.p: Order of the Group in Discrete Log 

Dl.t: Time to break Discrete Log 


Symbols for node GNFS 


Gnfs.c: 

Gnfs.t: 

Gnfs.n: 


constant 

time 

n 


Symbols for node EF-ACHA of the Schnorr Digital Signature Scheme 


EfACma.R 
EfACma.e 
EfACma.T 
EfACma.q 


Number of queries to the signing oracle 
Probablility of success of the attack 
Time to break Schnorr Signature under EF-ACMA 
Number of queries to the random oracle 


Symbols for node MGNFS 

HGnfs.n: n 

MGnfs.t: time 


Symbols for node Pollard's Rho Attack 

Pr.t: Time 

Pr.n: Keylength 

Symbols for node Subgroup Discrete Log Problem 

Sdl.t: Time to break Subgroup Discrete Log 

Sdl.p: Order of group in Subgroup Discrete Log 

Sdl.q; Order of subgroup in Subgroup Discrete Log 

Figure 5.13: Attack and objective symbols for the Schnorr case study. 


For Case 1, a sample run of our software tool is provided in Figures 5.14 and 5.15, showing 
values assoeiated with eaeh node and edge. In this ease, the level of effeetive seeurity is 
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determined to be « 2^^-^ when using the following security parameters: the order of the 
group is the order of the subgroup is 2^^®, the probability of success to 1.0, the number 

of queries to the both Break EF-ACMA random oracles as 2^^'^, the number of queries to 
the random oracle within the Schnorr reduction to 2^^. In reality, the random oracle 
parameters are inferable based on running time bounds; however, we defer to future work 
enhancements to employ conservative symbolic substitution—i.e., symbolic re-writing of 
expressions based on conservative relations—rather than our more simple approach of 
conservative value substitution. 


The values for node EF-ACMA of the Schnorr Digital Signature Scheme are as follows: 

EfACma.R 2''31.50e00ee000000 
EfACma.e 1 

EfACma.T 2''31.6191011974573 
EfACma.q 2''31.5000000000000 


The values for node Subgroup Discrete Log Problem are as follows: 

Sdl.t 2''80 

Sdl.p 2''1024 

Sdl.q 2''160 


The values for node Discrete Log Problem are as follows: 

Dl.p 2''1024 

Dl.t 2''86.7661192502810 


The values for node MGNFS are as follows: 


HGnf s. n 2''1024 

HGnfs.t 2''86.7661192502810 


Figure 5.14: Case 


1 output, showing node data when solving for cost. 
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The 

values 

for edge 

EF-ACHA <=> Subgroup Discrete Log i 



EfACma.R 

2''31.50G0eG0eG0eG0 



EfACma.T 

2''31.6191011974573 



Sdl.q 

2''160 



Sdl.t 

2''80 



EfACma.e 

1 



EfACma.q 

2^31.5000000000000 

The 

values 

for edge 

EF-ACMA <=> Subgroup Discrete Log i 



Sdl.t 

2''80 



EfACma.e 

1 



EfACma.T 

2''20 



EfACma.q 

2A19 

The 

values 

for edge 

Subgroup Discrete Log <=> Discrete 



Sdl.t 

2''86.7661192502810 



Sdl.p 

2''1024 



Dl.p 

2''1024 



Dl.t 

2''86.7661192502810 

The 

values 

for edge 

Discrete Log <=> Exhaustive Search 



Es.n 

2''1024 



6s.t 

2''1023 



Dl.p 

2''1024 



Dl.t 

2''1023 

The 

values 

for edge 

Discrete Log <=> Pollard’s Rho are 



Pr.t 

2''512 



Dl.p 

2''1024 



Pr.n 

2''1024 



Dl.t 

2A512 

The 

values 

for edge 

Dl <=> Meta GNFS are as follows: 



Dl.p 

2''1024 



MGnfs.n 

2''1024 



MGnfs.t 

2''86.7661192502810 



Dl.t 

2''86.7661192502810 

The 

values 

for edge 

M <=> Q are as follows: 



Gnfs.c 

1.92299942707654 



Gnfs.t 

2'^86.7661192502810 



MGnfs.n 

2''1024 



MGnfs.t 

2''86.7661192502810 



Gnfs.n 

2''1024 

The 

values 

for edge 

Discrete Log <=> Shank’s Baby-step 



BsGs.n 

2''1024 



Dl.p 

2''1024 



BsGs.t 

2''512 



Dl.t 

2''512 

The 

values 

for edge 

Subgroup Discrete Log <=> Pollard': 



Sdl.t 

2''80 



Pr.t 

2''80 



Sdl.q 

2''160 



Pr.n 

2''160 


s Rho are as follows: 


Figure 5.15: Case 1 output, showing edge data when solving for cost. 


For Case 2, a sample run of our software tool is provided in Figures 5.16 and 5.17, showing 
values assoeiated with eaeh node and edge. Providing 2^^-^ as the time bound for node 
Break EF-ACMA eorresponds to deelaring that the best-known attaeks breaking EF-ACMA 
must take a time exeeeding 2^^ -^, whieh provides 31.5 bits of effeetive seeurity. The analysis 
yields that, to ensure this level of seeurity, one must ehoose the order of the subgroup to be 
at least« 2^^*^. 
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The values for node EF-ACMA of the Schnorr Digital Signature Scheme are as follows: 

EfACma.R 2''31.5000000000000 

EfACma.e 1.00000000000000 
EfACma.q 2''31.5000000000000 

EfACma.T 2''31.5000000000000 


The values for node Subgroup Discrete Log Problem are as follows: 

Sdl.q 2''159.761797605085 
Sdl.p 2''159.761797605085 
Sdl.t 2''79.8808988025427 


The values for node Discrete Log Problem are as follows: 


Dl.p 2''159.761797605085 

Dl.t 2''79.8808988025427 


Figure 5.16: 
parameters. 


Case 2 output, showing node data when solving for security 


38 





The values for edge EF-ACMA <-> Subgroup Discrete Log (Pointcheval and Stern) are as follows: 


EfACma.R 

EfACma.e 1.DeoDDeeeoDeDee 

EfACma.q 2^31.50e&0eDe&0000 

EfACma.T 2''31.50000eD0&00d0 

Sdl.q 2'^159.761797605085 

Sdl.t 2^79.8808988025427 


The values for edge EF-ACMA <=> Subgroup Discrete Log (Schnorr) are as follows: 

EfACma.e 1.00000000000000 
Sdl.t 2''79.8808988025427 

EfACma.q 2^31.5000000000000 

EfACma.T 2^31.5000000000000 


The values for edge Subgroup Discrete Log <=> Discrete Log are as follows: 


Sdl.p 

2^159.761797605085 

Dl.p 

2''159.761797605085 

Sdl.t 

2'^79.8808988025427 

Dl.t 

2^^79.8808988025427 


The values for edge Discrete Log <=> Exhaustive Search are as follows: 


Es.n 

2^80.8808988025427 

Dl.p 

2''80.8808988025427 

Es.t 

2''79.8808988025427 

Dl.t 

2''79.8808988025427 


The values for edge Discrete Log <*> Pollard's Rho are as follows: 


Pr.n 

2^159.761797605085 

Dl.p 

2^^159.761797605085 

Dl.t 

2''79.8808988025427 

Pr.t 

2^79.8808988025427 


The values for edge Discrete Log <=> Shank's Baby-step Giant-step are as follows: 


BsGs.t 2''79.8808988025427 
Dl.p 2''159.761797605085 
D1. t 2''79.8808988025427 
BsGs.n 2''159.761797605085 


The values for edge Subgroup Discrete Log <~> Pollard's Rho are as follows: 


Pr.n 

2''159.761797605085 

Sdl.q 

2''159.761797605085 

Sdl.t 

2^79.8808988025427 

Pr.t 

2'^79.8808988025427 


Figure 5.17: Case 2 output, showing edge data when solving for 
parameters. 


secu 
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While testing our software tool, we diseovered it was eapable of solving for time within 
the GNFS attack, however solving for parameters proved more complex. We suspect 
the problem involved limits associated with the symbolic solver: SymPy appears to lack 
solvers able to handle computing n, given T and c, in the super-polynomial sub-exponential 
relationship for attacks employing the general number field sieve: 

T = exp(clnn^''^ Inlnn^^^). 

As a result, the node for the GNFS attack and the edge connecting it to the rest of the tree 
are missing from Figures 5.16 and 5.17. We leave for future work further verification of 
this problem and investigation into solutions or alternatives for this scenario. 

Comparing the results of our analyses to existing guidance. Figure 5.18 displays a selection 
of the key-length guidance for schemes based on the security of the discrete log problem, 
equating these to the cost of security for a symmetric scheme (i.e., characterizing its 
effective security). The Schnorr signature scheme employs discrete log assumptions. The 
“key” and “group” parameters from Figure 5.18 can be equated to the symbols Sdl.q and 
Sdl.p, respectively, in our case study (see Figure 5.13). 



Figure 5.18: Parameters for discrete log schemes, for key size 160 and 
a discrete log group size 1024. Source [3]: D. Giry. (2015). BlueKrypt- 
cryptographic key length recommendation. [Online]. Available: http://www. 
keylength.com. 
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Given a 160-bit subgroup and 1024-bit group, our software tool returns an effeetive seeurity 
of 80 bits for the Break Subgroup Discrete Log Problem seeurity objeetive (see Figure 5.14), 
matehing the effective security for many recommendations from Figure 5.18. Given 224-bit 
subgroup and 2048-but group, our software tool returns an effective security of 112 bits; 
interestingly, this is less than that claimed by the BSI recommendation from Figure 5.18. 
Using a 128-bit target effective security. Figure 5.19 summarizes the discrete log parameters 
from existing guidance and Figure 5.20 shows our results. 



Figure 5.19: Parameters for discrete log schemes, comparable in strength 
to 128-bit symmetric encryption. Source [3]: D. Giry. (2015). BlueKrypt- 
cryptographic key length recommendation. [Online]. Available: http://www. 
keylength.com. 


The values for node Subgroup Discrete Log Problem are as follows: 

Sdl.t 2''128 
Sdl.q 2''256 
Sdl.p 2''256 


The values for node Discrete Log Problem are as follows: 

Dl.t 2''128 

Dl.p 2''256 

Figure 5.20: Results from our software tool using 128-bit effective security. 
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CHAPTER 6: 
Conclusion 


We have described the current complexity and methodology to reason about cryptographic 
schemes, using reductionist proofs and data about known attacks for the practice-oriented 
goal of parameter selection. State-of-the-art is to employ generic, conservative recommen¬ 
dations published periodically, which are not necessarily current or informed by recently 
disclosed attacks. We developed a proof-of-concept software tool capable of reasoning 
about keylength for cryptographic schemes using machine-readable proof metadata. In 
support of this, we formalized reasoning about cryptographic adversaries within the attack 
tree model, and expanded attack trees to include proof reductions. 

For this tool, we described a concept of operations, use cases and design goals. We argued 
the software tool should be able to provide recommendations about keylength when given 
a set of parameters, as well as provide parameters necessary to achieve a target effective 
security. From there we presented the software design to achieve the stated goals and 
provided the algorithms to implement the software. We validate our software tool utilizing 
the Schnorr public-key signature scheme as a non-trivial case study. 

While our prototype had some limitations unrelated to our methodology, overall we showed 
that automating reasoning about keylength and effective security is achievable. When 
the attack and proof metadata is provided in a machine-readable format, our software 
tool achieved the desired goals of providing accurate and timely information specific to a 
particular scheme. Additionally, modularity and extensibility were achieved by designing 
the software tool in a way that allows experts to contribute knowledge from their domain, 
connecting it to a graph of other proof knowledge and facilitating its use in an automated 
framework. 


6.1 Future Work 

Further investigation into the limitations of our implementation, as presented in Section 5.6, 
is warranted. It will be necessary to verify that the limitations stem from the solver’s 
inability to handle particular situations, rather than a mistake in the implementation of 
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our software tool. Then, onee the problem is properly framed, the implementation ean 
be refitted. We also believe it is fruitful to expand the library of attaeks and objeetives 
to inelude other ease studies employing eonerete seeurity reduetions. Lastly, work ean be 
done to bridge automatie proof generation as explored in prior work, and automatie proof 
analysis as explored here. 
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